A host network server serves data to one or more client computers over a network. The server typically runs one or more services, each of a service type, which can be used by the clients. For example, the server might support the following service types email, web server, database, and the like. Each service is assigned a unique designated endpoint so that clients communicate with a particular service on the host computer by sending requests to, and receiving replies from, the designated endpoint for the particular service.
A client connects to a particular service, via a protocol, by specifying a locator ID and an endpoint ID that are known to both the client and the host server. Examples of common protocols include the named pipe protocol (NPP), the Transmission Control Protocol/Internet Protocol (TCP/IP), and the User Datagram Protocol/Internet Protocol (UDP/IP). For TCP/IP and UDP/IP, the locator ID is an Internet Host Address (or IP Address), and the endpoint ID is a port ID. For NPP, the locator ID is a NetBIOS name, and the endpoint ID is a named pipe name.
The endpoint ID is used to identify a particular endpoint on a machine. An endpoint is an object oh the server affected by remote operations from clients and local operations on servers. A named pipe is one example of an endpoint. A temporary file (/tmp/foo) is another example of an endpoint.
A common way for clients and services to agree on locator and endpoint IDs for a service (given a certain protocol) is to use the locator ID of the machine that the service runs on, and to use an endpoint ID permanently associated with the service type. This works because usually one service of a given service type runs per machine. As an example of permanently associating an endpoint ID with a service type, SMTP (Simple Mail Transfer Protocol) runs over TCP/IP and hardwires port 25 as the endpoint ID. As another example, clients of Microsoft's SQL Server 6.5 use the named pipe protocol and assume ".backslash.pipe.backslash.sq.backslash.query" as the endpoint ID. Even when using TCP/IP where IP addresses can be specified, protocols layered above it may not provide the option to specify the IP address (e.g., DCOM RPC (distributed component object model--remote procedure call) with TCP/IP bindings). A port can be supplied, but the address listened on is always "INADDR_ANY".
On the client site, the locator ID and endpoint ID are unique, and the endpoint ID is typically hardwired. This hardwiring is done to make things easier for the user. The user only has to specify a machine name.
Implicit in the conventional processes is the assumption that each machine will only be running one instance of the service. However, current server technology allows administrators to run multiple instances of the same service on a single machine. For example, a database administrator might wish to run multiple instances of the SQL database service so that more physical memory can be used than can be addressed by a single address space. In this case, one instance of SQL covers one address space and another instance of SQL covers another address space. To the client, each SQL instances functions as its own service running on its own machine. In this manner, the physical host server can be said to support multiple "virtual services" on multiple "virtual servers".
As another example, it is not uncommon for a Web server to support thousands of domains on the same Web service. To the client, however, each domain functions as its own service as if running on its own HTTP (Hypertext Transfer Protocol) server on its own machine. Here again, one physical host server is effectively running multiple "virtual services" on multiple "virtual servers".
A fault tolerant system in computer clustering is another context in which running multiple instances of the same service is desired. A computer cluster is made up of multiple computers interconnected by a network. Services, and data managed by the services, are distributed across the various computers in an effort to balance the load placed on any one computer. A fault tolerant system is designed into the computer cluster to accommodate failure of a computer, or component therein, within the cluster. When a computer fails, the services and resources handled by the failed computer are shifted to one or more other computers in the cluster to prevent loss of services to the clients. In this setting, there may arise a need to run multiple instances of a service on the same host machine. In the database arena, for example, a computer cluster configured to run multiple SQL services across multiple machines might be forced, due to a failure of one or more machines, to run multiple instances of the SQL service on one machine.
Unfortunately, inning multiple instances of the same service on a single machine creates a problem in how the clients connect to the instances. When multiple instances live on one machine, the endpoint IDs are no longer unique. Both the locator ID and the endpoint ID need to be considered to uniquely identify the instance of the service. However, in some API's that use the protocols (e.g., named pipe interface) the locator ID is stripped away because the location is assumed to be "here" at the local computer.
In addition, many server operating systems do not allow more than one instance of a service to bind to the designated endpoint for that service. As a result, other instances remain idle until they are bound to the endpoint. For example, such operating systems such as Windows NT operating system from Microsoft Corporation and the OS/2 operating system from IBM do not permit more than one instance of a service to bind to the designated named pipe for that service. Since only ode instance of a service is bound to the named pipe at any one time, the other instances are left idle, waiting for their opportunity to bind to the named pipe.
Abandoning the conventional protocols is not an option. Many existing client applications across many diverse platforms connect to services using the conventional protocols. Eliminating the protocols would require rewriting the client applications.
Accordingly, there is a need to improve server operating systems to enable multiple instances of a service on the same machine to bind concurrently to endpoints of the client-server protocols.